Security Evaluation of Apple’s iPhone

Executive Summary The Apple iPhone was released to much fanfare on June 29, 2007. Because of the large amount of personal information stored on these mobile devices, we decided to conduct a security analysis of the iPhone. The iPhone's applications for surfing the web and checking emails are potentially at risk to remote attacks. We wanted to determine exactly how well the software on the iPhone was designed to resist such attacks. The iPhone runs a stripped down and customized version of Mac OS X on an ARM processor. Much of the device's claimed security is reliant on its restrictions against running third party applications. Only Javascipt code can be executed in the Safari web browser, ensuring that all such code executes in a " sandbox " environment. Many of the features of Safari have also been removed, such as the ability to use plug-ins such as Flash. Likewise, many filetypes cannot be downloaded. These actions serve to reduce the attack surface of the device. However, there are serious problems with the design and implementation of security on the iPhone. The most glaring is that all processes of interest run with administrative privileges. This implies that a compromise of any application gives an attacker full access to the device. Like the desktop versions of Mac OS X on which its operating system is based, the iPhone also does not utilize widely accepted practices, such as using address randomization or non-executable heaps, to make exploitation more difficult. These weaknesses allow for the easy development of stable exploit code once a vulnerability is discovered. To demonstrate these security weaknesses, we created an exploit for the Safari browser on the iPhone. We used an unmodified iPhone to surf to a malicious HTML document that we created. When this page was viewed, the payload of the exploit forced the iPhone to make an outbound connection to a server we controlled. The compromised iPhone then sent personal data including SMS text messages, contact information, call history, and voice mail information over this connection. All of this data was collected automatically and surreptitiously. After examination of the filesystem, it is clear that other personal data such as passwords, emails, and browsing history could be obtained from the device. We only retrieved some of the personal data but could just as easily have retrieved any information off the device. Additionally, we wrote a second exploit that performs …